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configuration protocol (DHCP) service 



(57) The present invention discloses a method and 
system for monitoring and optimizing performance and 
availability of a Dynamic Host Configuration Protocol 
(DHCP) sewice provided by one or a plurality of DHCP 
senders (602) in an Internet Protocol (IP) network com- 
prising one or a plurality of IP subnetworks. 

The method comprises in a DHCP server (602) the 
steps of: 

• defining one or a plurality of groups of subnetworks, 
a group of subnetworks comprising one or a plural- 
ity of subnetworks; 

• retrieving Information related to resources, in par- 
ticular IP addresses, allocated within said DHCP 
server to each group of subnetworks; 

• transferring said information to a DHCP service 
monitoring system (600). 

The method comprises in a DHCP sen^ice monitor- 
ing system (403) the steps of: 

• retrieving (501 to 505) from one or a plurality of DH- 
CP servers (401), information related to resources, 
in particular IP addresses, allocated within each 
DHCP server (401 ) to groups of subnetworks, each 
group of subnetworks comprising one or a pluariity 
of sut}networks; 

• aggregating (506 to 511) the information for each 
group of subnetworks. 



DHCP Servioe Moniloring System 




DHCP Service 
Monitoring ^rstem 
(600) 
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Description 

Technicai field of the Invention 

[0001] The present invention relates to computer net- 
works, and more particularly to a method and system in 
an Internet Protocol (IP) network for optimizing perform- 
ance and availability of a Dynamic Host Configuratkxi 
Protocol (DHCP) senfice provided by a plurality of DH- 
CP sen/ers. 

Background art 

INTERNET 

[0002] Internet is a global network of computers and 
computers networks (the "Net"). The Internet connects 
computers that use a variety of different operating sys- 
tems or languages, including UNIX, DOS. Windows. 
Macintosh, and others. To facilitate and albw the com- 
munication among these various systems and languag- 
es, the Intemet uses a language referred to as TCP/IP 
(■Transmlssk)n Control Protoool/lntemet Protocol"). 
TCP/IP protocol supports three basic applk:atk)ns on 
the Intemet: 

• transmitting and receiving electronic mail, 

• logging into remote computers (the ■Telnet'), and 

• transferring files and programs from one computer 
to another ('FTP' or Tile Transfer Protocol"). 

[0003] One of the object of TCP/IP is to interconnect 
networks and to provkie an universal communication 
sen^ices: an Inter-network, or Intemet. Each physical 
network has its own technology-dependent communba- 
tion interface, in the form of a programming interface 
that provides bask; communk:ation functions (primi- 
tives). Communication servfces are provkied by a soft- 
ware that runs between the physical network and user 
applications. This software provides a common Inter- 
face for these applications, independent of the underly- 
ing physical network. The architecture of the physrcal 
networks is hidden from the user. 
[0004] The Intemet protocol Is still evolving through 
the mechanism of Request For Comments (RFC). New 
protocols (mostly applcatkxi protocols) are designed 
and implemented by researchers. They are brought to 
the attention of the Intemet community in the fonn of an 
Intemet Draft (ID). The largest source of IDs is the In- 
temet Engineering Task Force (IETF). 

IP ADDRESSES 

[0005] To interconnect two networks, a computer sys- 
tem able to f onward packets from one network to the oth- 
er is attached to both networks. Such a mach ine is called 
a router. The term "IP router" is also used because the 
routing functbn is part of the IP layer of the TCP/IP pro- 



tocol. 

[OOOq IP addresses are used by the IP protocol to 
unkfuely identify a host on the Intemet (Strk:tly speak- 
ing, an IP address identifies an interface that is capable 

5 of sending and receiving I P datagrams, and one system 
can have multiple such interfaces. However, both hosts 
and routers must have at least one IP address, so this 
simplified definition is acceptable). IP datagrams (the 
basic data packets exchanged between hosts) are 

10 transmitted by a physical network attached to the host 
and each IP datagram contains a source IP address and 
a destination IP address. 

[0007] IP addresses are represented by a 32-bit un- 
signed binary value which is usually expressed in a dot- 
t5 ted decimal fomiat. For example, 9.167.5.8 is a valid In- 
temet address. The numerk; form is used by the IP soft- 
ware. The mapping between the IP address and an eas- 
ler-to-read symbolic name, for example myhost.ibm. 
com. is done by the Domain Name System 

20 

IP SUBNETS 

[0008] Due to the expbsive growth of the Intemet, the 
principle of assigned I P addresses became too inflexible 
to allow easy changes to local network configurations. 
Those changes might occur when: 

• A new type of physical network is installed at a k>- 
cation. 

30 • Growth of the number of hosts requires splitting the 
\oca\ network into two or nnore separate networks. 

• Growing distances require splitting a network into 
smaller networks, with gateways between them. 

35 [0009] To avokJ having to request addltfonal IP net- 
work addresses in these cases, the concept of subnets 
was introduced. The assignment of subnets can be 
done locally, as the whole network still appears to be 
one IP network to the outskle world. 

40 [0010] The host number part of the IP address is sub- 
divided again into a network number and a host number 
This second network is termed a subnetwork or subnet. 
The main network now consists of a number of subnets 
and the IP address is interpreted as: 

4S <network numbenxsubnet numberxhost 
number> 

[0011] The combination of the subnet number and the 
host number is often termed the \oca\ address or the lo- 
cal part. Subnetting is implemented in a way that is 

so transparent to rennote networks. A host within a network 
that has subnets is aware of the subnetting but a host 
In a different network is not; it still regards the local part 
of the IP address as a host number. 
[0012] The divisbn of the kxa\ part of the IP address 

ss into subnet number and host number parts can be cho- 
sen freely by the k>cal administrator; any bits in the local 
part can be used to form the subnet. The division is done 
using a subnet mask which is a 32 bit number. Zero bits 
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in the subnet mask indicate bit positions ascribed to the 
host number, and ones indicate bit positions ascribed to 
the subnet number. The bit positions in the subnet mask 
belonging to the network number are set to ones but are 
not used. Subnet masks are usually written in dotted 
decimal form, like IP addresses. 

DOMAIN NAMES 

[0013] The host or computer names (like www.entre- 
prise.com) are translated into numerk: I ntemet address- 
es (like 1 94.56.78.3). and vice versa, by using a method 
called DNS ('Domain Name Sen/ice"). DNS is support- 
ed by network-resident servers, also known as domain 
name servers or DNS servers. 

DYNAMIC IP 

[001 4| There are generally three pieces of information 
needed by a system in order to be able to communicate 
on a TCP/IP network: 

• an IP address (to uniquely ktentify the system on 
the network), 

• a subnet mask (to determine the network and sub- 
net parts of the address), and 

• the address of at least one router (if the system is 
to be able to communicate with other devk:es out- 
side of its immediate subnet). 

[0015] These three values represent the bare mini- 
mum of informatbn that must be programmed into each 
and every device for partk;ipating in the TCP/IP workJ. 
Often the number of necessary parameters will be much 
higher. With the exponential growth rate of networking 
today, it is easy to see that manual programming of 
these values into every device that is to attach to the 
network represents a major administrative workbad. 
[0016] The increasingly mobWe nature of the end us- 
ers also raises problems with regard to configuration of 
network devbes. It is possible to alkxate multiple sets 
of configuration parameters to a devk:e, but: 

• this obviously means even more workk>ad for the 
administrator, 

• this is wasteful with respect to the number of IP ad- 
dresses allocated. 



concentrators and so on . It allows a minimum I P protocol 
stack with no configuration information to obtain enough 
Informatbn to begin the process of downbading the 
necessary boot code. BCX)TP does not define how the 

s downloading is done, but this process typically uses 
TFTP "Trivial File Transfer Protocol (TFTP)" as de- 
scribed In RFC 906 - Bootstrap Loading Using TFTP 
Although still widely for this purpose by diskless hosts, 
BOOTP is also commonly used solely as a mechanism 

10 to deliver configuration informatbn to a client that has 
not been manually configured. The BOOTP process in- 
volves the folbwing steps: 

• 1 . The client determines its own hardware address; 
*5 this is normally in a ROM (Read Only Memory) on 

the hardware. 

• 2. A BOOTP client sends its hardware address in a 
UDP (User Datagram Protocol) datagram to the 

20 sender, if the client knows its IP address and/or the 
address of the server, it should use them, but in gen- 
eral BOOTP clients have no IP configuratbn data 
at all. If the client does not know its own IP address, 
it uses 0.0.0.0. if the client does not know the sen^- 

25 efs IP address, it uses the limited broadcast ad- 
dress (255.255.255.255). The UDP port number is 
67. 

• 3. The sender receives the datagram and looks up 
30 the hardware address of the client in its configura- 
tion file, whbh contains the client's IP address. The 
sender fills in the remaining fiebs in the UDP data- 
gram and returns it to the client using UDP port 68. 

^ • 4. When it receives the reply, the BOOTP client will 
record its own IP address and begin the bootstrap 
process. 

ipol 9] BOOTP is a draft standard protocol. Its status 
^ is recommended. The BOOTP specifications can be 
found in RFC 951 - Bootstrap Protocol. There are also 
updates to BOOTP, some relating to inter operabiiity 
with DHCP (Dynamic Host Configuratbn Protocol), de- 
scribed in RFC 1542 - Clarificatbns and Extensbns for 
^ the Bootstrap Protocol, which updates RFC 951 and 
RFC 21 32 - DHCP Optbns and BOOTP Vendor Exten- 
sbns. 



[0017] Several components of TCP/IP help automate 
device configuratbn, reduce the number of IP address- 
es allocated, and/or cope with the demands of the mo- 
bile user. 

BOOTSTRAP PROTOCOL (BOOTP) 

[001 8] The BOOTP protocol was originally devebped 
as a mechanism to enable diskless hosts to be remotely 
booted over a network as workstations, routers, terminal 



DYNAMIC HOST CONFIGURATION PROTOCOL 
(DHCP) 

[0020] The Dynamic Host Configuration Protocol 
(DHCP) provides a framework for passing configuration 
informatbn to hosts on a TCP/IP network. DHCP is 
based on the BOOTP protocol, adding the capability of 
automatic allocation of reusable network addresses and 
additional configuration options. DHCP messages use 
UDP port 67, the BOOTP server's well-known port and 



so 



ss 
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UDP port 68, the BOOTP client's well-known port. DH- 
CP consists of two components: 

• 1 . A protocol that delivers host-specific configura- 
tion parameters from a DHCP Sender to a host. 

• 2. A mechanism for the allocation of temporary or 
permanent network addresses to hosts. 

[0021] IP requires the setting of many parameters 
within the protocol implementation software. Because 
IP can be used on many dissimilar kinds of network 
hardware, values for those parameters cannot be 
guessed at or assumed to have correct default values. 
The use of a distributed address allocation scheme 
based on a polling / defence mechanism, for discovery 
of network addresses already in use, cannot guarantee 
unique network addresses because hosts may not al- 
ways be able to defend their network addresses. DHCP 
supports three mechanisms for IP address allocation: 

• 1 . Automatic allocation : DHCP assigns a perma- 
nent IP address to the host. 

• 2. Dynamic allocation : DHCP assigns an IP ad- 
dress for a limited period of time. 

• 3. Manual alkx^ation : The host's address is as- 
signed by a network administrator. 

[0022] DHCP Is a draft standard protocol. Its status is 
elective. The current DHCP specificatbns can be found 
in RFC 2131 - Dynamic Host Configuratbn Protocol and 
RFC 21 32 - DHCP Opttons and BOOTP Vendor Exten- 
sions. 

Configuration Parameters Repository 

[0023] DHCP provides persistent storage of network 
parameters for network clients. A DHCP Server stores 
a key-value entry for each client, the key being some 
unique identifier, for example an IP subnet number and 
a unique identifier within the subnet (normally a hard- 
ware address), and the value contains the configuratkxi 
parameters last allocated to this partk:ular client. 
[0024] One effect of this is that a DHCP client will tend 
to always be allocated the same I P address by the send- 
er, provided the pool of addresses is not over-sub- 
scribed and the previous address has not already been 
alkx»ted to another client. 

DHCP Considerations 

[0025] DHCP dynamic alkx^atkxi of I P addresses and 
configuration parameters relieves the network adminis- 
trator of great deal of manual configuration work. The 
ability for a device to be moved from network to network 
and to automatically obtain valid configuratk)n parame- 
ters for the current network can be of great benefrt to 
mobile users. Also, because IP addresses are only al- 
located when clients are actually active, it is possible, 



by the use of reasonably short lease times and the fact 
that mobile clients do not need to be allocated more than 
one address, to reduce the total number of addresses 
in use in an organization. However, the following shoukJ 
s be considered when DHCP is being implemented: 

• DHCP is built on UDP, which is, as yet. inherently 
insecure. In normal operation, an unauthorized cli- 
ent could connect to a network and obtain a valid 

10 IP address and configuration. To prevent this, it Is 
possible to preallocate IP addresses to particular 
MAC (Medium Access Control) addresses (similar 
to BOOTP), but this increases the administratbn 
workload and removes the benefit of recycling of 

IS addresses. 

• Unauthorized DHCP Sen/ers could also be set up, 
sending false and potentially disruptive informatbn 
to clients. 

20 

• In a DHCP environment where automatic or dynam- 
ic address allocatbn is used, it is generally not pos- 
sible to predetermine the IP address of a client at 
any partKUlar point in time. In this case, if static DNS 

2S ( Domain Name Server) sen/ers are also used, the 
DNS servers will not likely contain valid host name 
to IP address mappings for the clients. If having cli- 
ent entries in the DNS is important for the network, 
one may use DHCP to manually assign IP address- 

30 es to those clients and then administer the client 
mappings in the DNS accordingly. 

BOOTP and DHCP inter operability 

3S [0026] The format of DHCP messages is based on the 
format of BOOTP messages, which enables BOOTP 
and DHCP clients to interoperate in certain circumstanc- 
es. Support for BOOTP clients at a DHCP Sen/er must 
be configured by a system administrator, if required. 

40 

DYNAlMiC DOIMAIN NAiME SYSTEiyi 

[0027] In order to take advantage of DHCP, yet still to 
be able to kx:ate any specific host by means of a mean- 
^ ingful label, such as its host name, the following exten- 
stons to the Domain Name System (DNS) are required: 

• A method for the host name to address mapping 
entry for a client in the domain name sender to be 

so updated, once the client has obtained an address 
from a DHCP Sen/er. 

• A method for the reverse address to host name 
mapping to take place once the client obtains its ad- 

ss dress. 

• Updates to the DNS to take effect immediately, with- 
out the need for intervention by an administrator. 
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• Updates to the DNS to be authenticated to prevent 
unauthorized hosts from accessing the network and 
to stop impostors from using an existing host name 
and remapping the address entry for the unsuspect- 
ing host to that of its own. 

• A method for primary and secondary DNS servers 
to quicldy forward and receive changes as entries 
are being updated dynamically by clients In short, 
a secure Dynamic Domain Name System (DDNS) 
is necessary. 

[0Q28] In summary, in the DHCP and DDNS environ- 
ment, DHCP provides a device with a valid IP address 
for the point at which it is attached to the network. DDNS 
provides a method of locating that devtee by its host 
name, no matter where that device happens to be at- 
tached to a networic and what IP address it has been 
albcated. 

[0029] More explanatkxis about the domain present- 
ed in the above sections can be found in the following 
publications incorporated herewith by reference: 

• TCP/IP Tutorial and Technical Overview by Martin 
W. Murhammer, Orcun Atakan. Stefan Bretz, Larry 
R. Pugh, Kazunari Suzuki, DavkJ H. Wood pushibed 
by IBM International Technical Support Organiza- 
tkxi. 

• 'Internet in a nutshell" by Valerie Querela, published 
by aReilly, October 1997. 

PROBLEM 

[0030] The problem is to monitor the utilization of a 
Dynamic Host Configuratfon Protocol (DHCP) sewice 
provided by one or a plurality of DHCP senders, in order 
to optimally adjust configuration parameters. Due to the 
nature of DHCP protocol which is based on UDP 
BOOTP broadcast, the DHCP service is provided to the 
DHCP Client by the fastest" DHCP Sewer to answer 
As a consequence, in a multiple DHCP Servers environ- 
ment, when a DHCP Server fails or when a DHCP Serv- 
er reachs its maximum capacity, the DHCP Sen/ers 
wh»h are still available continue to provide a DHCP 
Se wice and to answer DHCP Client requests. The avail- 
able DHCP Sewers continue to provide the service until 
they reach their maximum capacity Eventually the DH- 
CP Sewice may fait because available DHCP Sewers 
cannot support the total bad. 
[0031] A single DHCP Sewer may be configured to 
provide a DHCP Sewice to multiple subnetworks or 
groups of subnetworks. In this case, the DHCP Sewer 
is configured with one pool of IP addresses per subnet- 
woric. The capacity or size of a pool is defined by the 
number of IP adresses this pool can manage. 
[0032] In addition, for better resilience and better per« 
formance, a group of subnetworks can be administered 
by multiple DHCP Sewers. In this case, the DHCP Sew- 



ice is provided by this plurality of DHCP Sewers. 
[0033] Note : in the present invention, 'a group of sub- 
networks" comprises one or multiple subnetworics also 
called "IP subnets' generally kx:ated in a same geo- 
s graphical area. 

[0034] The problems are then to: 

• monitor the utilizatkxi of the DHCP Sewice for each 
group of subnetworks. 

10 • monitor the pools of I P addresses configured within 
each DHCP Sewer. 

• correlate and nrK>nitor for each group of subnet- 
works, the utilizatkm of the pools of IP addresses 
configured on multiple DHCP Sewers 

15 • detect any capacity problem on DHCP Sewers, in 
order to anticipate any DHCP Sewice degradatk>n 
or disruption. 

[0035] The DHCP Sewice provided when one DHCP 
20 Sewer has reached its maximum capacity is degraded 
because the DHCP Sewers which are still available 
have to handle additbnal load. The monitoring of a DH- 
CP Sewbe without analysis of its utilisatbn cannot not 
lead to an efficient antbipation of the problems, in par- 
25 ticular disruptbn or degradation of the DHCP Sewbe. 

Objects of the invention 

[0036] 

30 

• One object of the present invention is to provide a 
method for optimizing performance and availability 
of a DHCP Sewice. 

35 • It is a further object of the present inventbn to mon- 
itor the utilisation of a DHCP Sewice for each group 
of subnetworks. 

• It is another object of the present invention to mon- 
^ itor the pools of IP addresses configured within 

each DHCP Sewer. 

• It is yet another object of the present invention to 
correlate and monitor the utilization of the pools of 

45 IP addresses configured on multiple DHCP Sewers 
for each group of subnetworks. 

• It is yet another object of the present invention to 
detect any capacity problem on DHCP Sewers. 

so 

• It is another object of the present inventbn to check 
that every DHCP Sewer is correctly configured. 

Summary of the invention 

55 

[0037] The present invention discloses a method and 
system for monitoring and optimizing performance and 
availability of a Dynamb Host Configuration Protocol 
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(DHCP) service provided by one or a plurality of DHCP 
servers in an Internet Protocol (IP) network comprising 
one or a plurality of IP subnetworks. 
[0038] More partlcularly the present invention uses 
specific probes for collecting information related to the s 
utilization of IP address pools within said DHCP Serv- 
ers. 

[0039] The present invention also uses a DHCP Serv- 
ice Utilisation application for correlating the infonmation 
related to the utilizatbn of the IP address pools, and pro- io 
viding monitoring reports and statistics. 
[0040] The method comprises in a DHCP sender the 
steps of: 

• defining one or a plurality of groups of subnetworks, is 
each group of subnetworks comprising one or a plu- 
rality of subnetworks; 

• retrieving information related to resources. In par- 
tk:ular IP addresses, allocated within saki DHCP 
sen/er to each group of subnetworks; 20 

• transferring said informatbn to a DHCP senrice 
monitoring system. 

[0041] The method comprises in a DHCP sen/be 
monitoring system the steps of: 2S 

• retrieving from one or a plurality of DHCP servers, 
information related to resources, in particular IP ad- 
dresses, allocated within each DHCP sender to 
groups of subnetworks, each group of subnetworks 30 
comprising one or a plurality of subnetworks; 

• aggregating the information for each group of sub- 
networks. 

[0042] The present Inventions provides the folbwing 3S 
advantages: 

• Early detection of I P address shortage in pools con- 
figured within each DHCP Sender for each group of 
subnetworks. 40 

• Early detection of I P address shortage in pools con- 
figured on multiple DHCP Servers for each group 
of subnetworks. 

• Early detection of any capacity problem on DHCP 
Servers for each group of subnetworics in order to 45 
antrcipate any sen^ice degradation or disruption. 

• Production of DHCP Service utilisatk)n reports, for 
adjusting configuration of DHCP Servers (for exam- 
ple, increase of the size of an IP address pool for a 
specific group of subnetworks on a DHCP Server), so 

• No additional or specific hardware is mandatory. 

Drawlnga 

[0043] The novel and inventive features believed ss 
characteristics of the invention are set forth in the ap- 
pended claims. The invention itself, however, as well as 
a preferred mode of use, further objects and advantages 



thereof, will best be understood by reference to the fol- 
bwing detailed description of an illustrative detailed em- 
bodiment when read in conjunction with the accompa- 
nying drawings, wherein : 

• Figure 1 shows the IP address allocatbn to a DHCP 
Client by a DHCP Sender according to prior art. 

• Figure 2 is a view of a DHCP server probe according 
to the present inventbn. 

• Figure 3 is a flow chart of a DHCP sen/er probe ac- 
cording to the present inventbn. 

• Figure 4 is a view of a DHCP group probe according 
to the present inventbn. 

• Figure 5 is a flow chart of a DHCP group probe ac- 
cording to the present inventbn. 

• Figure 6 is a physbal view of a DHCP service nrran- 
itoring system according to the present inventbn. 

Prefmm/ embodiment of the invention 

[0044] The present inventbn relates to the monitoring 
of a DHCP service and more partbularty to a method 
and system for checking the size of IP address pools for 
a group of IP subnetworks among one or a plurality of 
DHCP senders. The present invention is based on the 
measure of utilization of IP address pools by means of 
probes. 

IP ADDRESS ALLOCATION 

[0045] Figure 1 describes the DHCP Client/Server in- 
teractbns when the DHCP Client does not know its net- 
work address. More partbularly, Figure 1 shows the ac- 
quisitbn mechanism by a DHCP Client of the IP address 
and the IP minimal configuration parameters from a DH- 
CP Sen/er within an IP network. The DHCP Client (1 01 ) 
broadcasts a request on its local physk:al subnet (103). 
The request is f onft^arded by any router having a BOOTP 
forwarding mechanism. When the request is received 
by a DHCP Server (102), the DHCP Sen/er checks 
whether it is able to answer the DHCP Client or not. If 
the DHCP Server has still some available IP address 
within its address database, a positive answer is re- 
lumed to the DHCP Client. The DHCP Client selects the 
first DHCP Sen/er for whbh a positive answer is re- 
ceived and confirms to this server its agreement. 
[0046] More particularly the allocation of a new net- 
work address comprises the folbwing steps: 

• The DHCP Client broadcasts a request on Its local 
physical subnet. The request may include some op- 
tions such as network address suggestion or lease 
duratbn. 
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• Each DHCP Server may respond with a message 
that includes an available network address and oth- 
er configuration options. The DHCP Sender may 
record the address as offered to the DHCP Client 

to prevent the same address being offered to other s 
DHCP Clients in the event of further messages be- 
ing received before the first DHCP Client has com- 
pleted its configuration. 

• The DHCP Client receives one or more messages 10 
from one or more DHCP Senders. The DHCP Client 
chooses one based on the configuration parame- 
ters offered and broadcasts a message that in- 
cludes the DHCP Sender identifier option to indicate 
which message it has selected and the requested is 
IP address option, taken from the DHCP Client IP 
address in the selected offer. 

• The DHCP Servers receive the messages broad- 
casted by the DHCP Client. Those DHCP Servers 20 
not selected use the message as notification that 
the DHCP Client has declined that DHCP Server's 
offer. The DHCP Sen/er selected in the nnessage 
commits the binding for the DHCP Client to persist- 
ent storage and responds with a message contain- 2S 
ing the configuratkm parameters for the requesting 
DHCP Client. 

• The DHCP Client receives the message with con- 
figuration parameters and performs a final check on 30 
the parameters. At this point the DHCP Client is 

configured. 

INTERNAL VIEW OF A DHCP SERVER PROBE 

3S 

[0047] Figure 2 is a logical view of a DHCP Server 
Probe (202). The DHCP Server Probe runs concurrently 
with the DHCP Sender application (201). The DHCP 
Server Probe (202) within the DHCP Server (200) de- 
temnines, the current number of alkx^ted IP addresses 40 
for each group of subnetworks and saves this informa- 
tion in a file (203) called "Server Utilisation File' (in a 
preferred embodiment, there is one entry in the Server 
Utilisatnn File for each group of subnetworks). A group 
of subnetworks is in fact a list of IP subnetworks (or IP 46 
subnets) stored in a file (204) generally called "Group 
File" (in a preferred embodiment, the file name is the 
group name for a better identificatton of the informatkxi). 
A workstatk)n broadcasting an IP address alk)cation re- 
quest from its local subnetwork, will be served by a ^ 
unique DHCP Sewer. The Group File (204) in a DHCP 
Sender comprises in fact the list of IP subnetworks be- 
longing to a same group. 

DYNAMIC VIEW OF A DHCP SERVER PROBE 55 

[0048] Figure 3 is a flow chart of a DHCP Server 
Probe as described in Figure 2. The DHCP Sender 



Probe is executed at given and regular period of times. 
Information collected by the probe is recorded in a file 
(Sen/er Utilisation File - 203) containing for each group 
of subnetworks, the total number of IP addresses within 
the pool and the number of IP addresses used or allo- 
cated The process comprises the following steps: 

• (301 ) The Sender Utilization File in the DHCP Server 
is opened. 

• (302) A test determines whether there is a Group 
File to process or not. 

• (31 3) If there is no more Group File to process, 
the Server Utilizatk>n File in the DHCP Sender 
is closed. 

• If there is still a Group File to process: 

• (303) The group name Is extracted from the 
Group File (in a preferred embodiment the 
group name is extrapolated from the Group 
File name). 

• (304) The list of subnetworks that belongs 
to the group Is extracted from the Group 
File. 

• (305) A first counter called Total Group 
Pool Size counter" is initialized for the 
group. This counter is used to determine 
the total number of IP addresses that can 
be alkx:ated to this group (available and al- 
located IP addresses). 

• (306) A second counter called Total Group 
Pool Used counter" is initialized for the 
group. This counter is used to determine 
the total number of IP addresses actually 
alkx^ated to this group. 

• (307) A test determines whether there is a 
subnetwork within the group to process or 
not. 

• If there is a subnetwork to process: 

• (308) The size of the pool associ- 
ated with the subnetwork is re- 
trieved from the DHCP Server Ap- 
plication. 

• (309) The size of the pool is added 
to the Total Group Pool Size 
stored in the Total Group Pool Size 
counter. 

• (310) The number of allocated IP 
addresses associated with the 
subnetwork is retrieved from the 
DHCP Server Application. 

• (311) The number of allocated IP 
addresses is added to the Total 
Group Pool Used stored in the To- 
tal Group Pool Used counter. 
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When all subnetworks have been 
processed: 

• (31 2) The Sender Utilisation File is 
updated with the folbwing infor- 
mation: 

• name of the group; 

• Total Group Pool Used; 

• Total Group Pool Size; 

• a time stamp. 
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If there Is a DHCP Server to process: 

• (503) A connection is established with the 
DHCP Server (401). 

• (504) The Server Utilisation File (402) is re- 
trieved from the DHCP Server. 

• (505) The connection with the DHCP Send- 
er is terminated. 

When there is no more DHCP Server to proc- 
ess: 



DHCP GROUP PROBE 

[0049] Figure 4 is a view of a DHCP Group Probe 
(405). The probe can be processed either In a DHCP 
Monitoring System (403) or in any DHCP Sender. The 
purpose of a DHCP Group Probe is to compute for each 
group of subnetworks administered by one or a plurality 
of DHCP Senders, the gtobal utilisation of the IP address 
pools. The DHCP Group Probe collects the information 
previously processed by DHCP Sewer Probes on DH- 
CP Senders (401). 

• The information is stored in the Server Utilization 
File (402) of each DHCP Sewer (401 ) administering 
the group. 

• DHCP Sewers are recorded in a list called "DHCP 
Sewers List File" (404). The collected information 
is then aggregated In several files (one per group) 
called 'Group Utilisation Files' (406). Each file con- 
tains all infoHDatbn related to the utilization of IP 
address pools for a given group, in particular the 
percentage of utilisatbn of IP addresses. To avoid 
any IP address shortage in IP address pools, spe- 
cific actions (for instance, increase of a pool size in 
a DHCP Sewer) can then be launched if, for in- 
stance, the computed percentage exceeds a pre- 
defined threshokJ. 

DYNAMIC VIEW OF A DHCP GROUP PROBE 

[0050] Figure 5 is a flow chart of a DHCP Group 
Probe. The probe is preferably executed at given and 
regular perkxis of time. The information for each group 
of subnetworks is collected in the different DHCP Sew- 
ers. A file (404) in the DHCP Monitoring System (403) 
contains an exhaustive list of the DHCP Sewers admin- 
istering each group of subnetworks. The following proc- 
ess in the DHCP Monitoring System (403) Is then exe- 
cuted: 

• (501 ) A DHCP Sewer (in a preferred embodiment, 
the DHCP Sewer name, or address) Is retrieved 
from the DHCP Sewers List File (404). 

• (502) A test determines whether there is still a DH- 
CP Sewer to process or not 



group, 

(510) The gfobal utilisation of the 
IP address pools for the group is 
recorded with a time stamp. 

(511) When there is no more 
group to process, a successful re- 
tum code is returned. 

DHCP SERVICE MONITORING SYSTEM 

SO [0051] Figure 6 is a view off a DHCP Sewfce Monitor- 
ing system (600) within an IPnetwork. A dedicated com- 
puter system can be used to run the DHCP Group 
Probes (601) and to collect the infonmation located in 
each DHCP sewer (602) by DHCP Sewer Probes (603). 

ss [0052] While the invention has been partbularly 
shown and described with reference to a preferred em- 
bodiment, it will be understood that various changes in 
form and detail may be made therein without departing 



• (506) An exhaustive list of the groups is ex- 
trapolated from the Sewer Utilisation Files 
previously retrieved from DHCP Sewers 
(note each Sewer Utilisation File contains 
group names, and a same group name 
may be present In multiple Sewer Utilisa- 
tion Files). 

20 

• (507) A test determines whether there is 
still a group to process or not: 

• If there is still a group to process: 

25 

• (508) Data for the group (Total 
Group Pool Used, Total Group 
Pool Size) are retrieved from 
Sewer Utilisatkxi Files. 

^ • (509) The global utilization of the 

IP address pools for the group is 
computed. In a preferred embodi- 
ment, the gbbal utilisation is equal 
to sum of Total Group Pool Used 

3S variables, divided by sum of all To- 

tal Group Pool Size variables. 

• An action (for instance an alert) 
can be sent if a predefined thresh- 
old has been reached for this 

40 
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from the spirit, and scope of the invention. 



Claims 

1. A method for monitoring and optimizing perform- 
ance and availability of a {Dynamic Host Configura- 
tion Protocol (DHCP) service provided by one or a 
plurality of DHCP servers (602) in an Internet Pro- 
tocol (IP) networic comprising one or a plurality of 
I P subnetworks, said method comprising In a DHCP 
server (602) the steps of: 

• defining one or a plurality of groups of subnet- 
works, each group of subnetworks comprising 
one or a plurality of subnetworks; 

• retrieving information related to resources, in 
particular IP addresses, allocated within said 
DHCP sender to each group of subnetworks; 

• transferring sab inf onmatbn to a DHCP service 
monitoring system (600). 

2. The method according to the preceding claim 
wherein the step of retrieving information related to 
resources allocated to each group of subnetworks 
comprises the further step of: 

• determining a total number of IP addresses 
presently allocated to each group of subnet- 
works, the total number of IP addresses of a 
group of subnetworks being equal to the sum 
of IP addresses presently alkx:ated to each 
subnetwork defined within sakJ group of sub- 
networks. 

3. The method according to any one of the preceding 
claims wherein the step of retrieving information re- 
lated to resources alkxated to each group of sub- 
networks comprises the further step of: 

• determining a total number of IP addresses that 
can be potentially allocated to each group of 
subnetworks, the total number of IP addresses 
of a group of subnetworks being equal to the 
sum of IP addresses that can be potentially al- 
located to each subnetwork defined within said 
group of subnetworks. 

4. The method according to any one of the preceding 
claims comprising the further step of: 

• storing the total number of IP addresses pres- 
ently allocated to each group and/or that can 
be potentially allocated to each group of sub- 
networks in a file (203) within the DHCP server. 

5. A system, in particular a DHCP server (200), adapt- 
ed for carrying out the method according to any one 



of the preceding claims. 

6. A computer readable medium comprising Instruc- 
tions adapted for carrying out the method according 

s to any one of steps 1 to 4. 

7. A method for monitoring and optimizing perform- 
ance and availability of a Dynamk: Host Configura- 
tion Protocol (DHCP) service provided by one or a 

10 plurality of DHCP servers (401 ) according to claim 
5 in an Internet Protocol (IP) network comprising 
one or a plurality of IP subnetworics, said method 
comprising in a DHCP senrice monitoring system 
(403) the steps of: 

IS 

• retrieving (501 to 505) from one or a plurality of 
DHCP senders (401 ), information related to re- 
sources, in partbular IP addresses, alkx^ted 
within each DHCP server (401) to groups of 

20 subnetworks, each group of subnetworks com- 

prising one or a plurality of subnetworks; 

• aggregating (506 to 511) said information for 
each group of subnetworks. 

2S 8. The method according to the preceding claim 
wherein the retrieved Information comprises for 
each DHCP sender a total number of IP addresses 
presently allocated to each group of subnetworks, 
the total number of IP addresses of a group of suk>- 
30 networks in a DHCP sender being equal to the sum 
of I P addresses presently allocated to each subnet- 
work defined within sakJ group of subnetworks. 

9. The method according to any one of claims 7 to 8 
3S wherein the retrieved information comprises for 

each DHCP sewer a total number of IP addresses 
that can be potentially alkx:ated to each group of 
subnetworks, the total number of IP addresses of a 
group of subnetworks in a DHCP sender being equal 
^ to the sum of IP addresses that can be potentially 
allocated to each subnetwork defined within said 
group of subnetworks. 

10. The method according to any one of claims 7 to 9 
^ comprising a first step of: 

• recording sab one or plurality of DHCP servers 
in a list (404); 

so 11 . The method according to any one of claims 7 to 1 0 
wherein the step of aggregating (506 to 51 1 ) said 
informatbn for each group of subnetworks compris- 
es the further step of: 

ss m building (506) a list of groups of subnetworics 
using informaton retrieved from DHCP send- 
ers. 



ss 
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12. The method according to any one of claims 7 to 11 18. A computer readable medium comprising instruc- 
wherein the step of aggregating (506 to 511 ) said tions adapted for carrying out the method according 

information for a group of subnetworks comprises to any one of steps 7 to 1 6. 

the further step of: 

5 

• determining a total number of IP addresses 
presently allocated to said group of subnet- 
works on all DHCP servers, the total number of 
IP addresses being equal to the sum of IP ad- 
dresses presently alkxated to sakJ group of io 
subnetworks in each DHCP server. 



13. The method according to any one of claims 7 to 1 2 
wherein the step of aggregating (506 to 511) said 
information for a group of subnetworks comprises is 
the further step of: 

• determining a total number of IP addresses that 
can be potentially albcated to saki group of 
subnetworks on all DHCP senders, the total 20 
number of I P addresses being equal to the sum 

of IP addresses that can be potentially alkxat- 
ed to saki group of subnetworks in each DHCP 
server. 

2S 

14. The method according to any one of claims 7 to 1 3 
wherein the step of aggregating (506 to 511) said 
information for a group of subnetworks comprises 
the further step of: 

30 

• dividing the total number of I P addresses pres- 
ently allocated to sakJ group of subnetworks on 
all DHCP sen/ers by the total number of IP ad- ^ 
dresses that can be potentially allocated to said 
group of subnetworks on all DHCP servers; 3S 

• comparing the result of the division with a pre- 
determined threshold; 

• triggering a corrective actkxi when this thresh- 
old is reached for a group of subnetworks. 

40 

15. The method according to any one of claims 7 to 14 
wherein the step of triggering a corrective actbn 
comprises the further step of: 

• triggering an alert; or/and 45 

• adjusting within one or a plurality of DHCP send- 
ers the number of IP addresses that can poten- 
tially be allocated to sakd group. 

16. The method according to any one of claims 7 to 15 so 
wherein the step of retrieving informatran is execut- 
ed at predefined or/and regular perkxis of time on 
request of the DHCP sen^ice monitoring system 
(403). 

ss 

17. A system, in particular a DHCP sen/ice monitoring 
system (403) adapted for cariying out the method 
according to any one of claims 7 to 16. 
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